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Summary of the Claimed Subject Matter per 37 CFR §4LS7(c)(l)(v) 

The invention provides a system and method for marking a computer or microprocessor's 
stack with signatures to indicate which portions of the stack were utilized by one or more re- 
entrant or object-oriented programming software code modules (pg. 8, lines 2-13). Addressing 
such needs in an object-oriented and re-entrant computing environment is especially challenging, 
as each code module can be duplicated during runtime, and the duplicates or "instances" of the 
code modules may execute simultaneously or concurrently. As such, simply having each unique 
code module place an identifier on the stack would not be sufficient, as it would be difficult to 
know which instance of each code module executed, when it executed, and what portion of the 
stack was dedicated or used by each instance (pg. 1 7, lines 13-1 8), 

To solve this problem, the invention performs the following steps as claimed in Claims 1 

and 7: 

(a) inserts "stack signing software" into one or more re-entrant or object-oriented 
programming code modules which are stored in a computer-readable medium 
(fig. 4 #45; pg. 15 lines 1 -3); 

(b) produces one or more executable programs containing one or more executable 
re-entrant or object oriented programming code modules containing said inserted 
stack signing software (fig. 4 #48, #49, #400; pg. 1 5 lines 4 - 7); and 

(c) upon subsequent execution of said executable re-entrant or object-oriented code 
modules, assigning unique module identifier values to said code modules by said 
stack signing software (pg. 17 line 19 - pg. 18 line 13, pg. 19 lines 5 - 8), wherein 
the stack signing software prevents module identifiers from having a same value 
for multiple instances of any re-entered or multiply instantiated code module (pg. 
17 line 19 - pg. 19 line 2), and pushing onto said processing stack said stack 
signatures within stack frames allocated to said code modules (pg. 1 9 lines 5-8). 
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Claim 13 sets forth a system embodiment of the present invention that interoperates with 

a software compiler, including: 

(a) a control operable by a user to indicate whether or not to insert stack 
signature marking code segments into application software modules (fig. 4 #44, 
pg. 14 lines 18 - 21; pg- 15 line 11 - pg. 16 line 15); 

(b) a code inserter which, responsive to the operation of the control means, 
searches for entry points and exits points in application software modules and 
inserts stack signature marking code segments following each entry point and 
prior to each exit point into said application software modules (fig. 4 #47, pg. 14 
line 22); 

(c) a compiler for producing one or more executable programs containing one 
or more executable re-entrant or object oriented programming code modules 
containing the inserted stack signing software (pg. 15 line 6); and 

(d) a software debugger enhanced such that upon execution of the executable re- 
entrant or object-oriented code modules, unique module identifier values are 
assigned to the code module instances by the inserted stack signing software, 
wherein the stack signing software prevents module identifiers from having a 
same value for multiple instances of any re-entered or multiply instantiated code 
module, and the stack signatures are pushed onto the processing stack (see 
disclosure references for the method and computer-readable medium claims 
above for these steps or operations). 



Grounds for Rejection For Which Review is Sought per 37 CFR §41.3 7(c)(1) (vi) 
Review by the Board is requested of the rejections of: 

(1) Claims 1 - 3 and 7 - 9 under 35 U.S.C. §103(a) as being unpatentable over U.S. 
patent 5,950,003 to Kaneshiro, et al. (hereinafter "Kaneshiro") in view of U.S. 
patent 6,807,583 to Hrischuk, et al. (hereinafter "Hrischuk"); 

(2) Claims 4 - 6 and 10 - 15 under 35 U.S.C. §103(a) as being unpatentable over 
Kaneshiro in view of Hrischuk in further view of U.S. patent 6,161,219 to 
Ramkumar, et al. (hereinafter "Ramkumar"); 
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(3) Claims 16 - 17 under 35 U.S.C. §103(a) as being unpatentable over Kaneshiro in 
view of Hrischuk, in further view of U.S. patent 6,862,696 to Voas (hereinafter 
"Voas"); and 

(4) Claim 1 8 under 35 U.S.C. §103(a) as being unpatentable over Kaneshiro in view 
of Hrischuk in further view of U.S. patent to Carter, et al (hereinafter "Carter") 

Arguments per 37 CFR §4L37(c)(l)(vU) 

Re jections of q»i»n« 1 - 3 and 7 - 9 nnder 35 U. S .C, S103(a) o ver Kaneshiro in view 

of Hrischuk 

Hrischuk is cited in the rationale for the rejections of Claims 1 - 3 and 7 - 9 as the 
secondary reference in this combination to teach instrumentation of object oriented executable 
code and instance counters because Kaneshiro does not teach these aspects of our independent 
claims. In particular, it was argued that Hrischuk teaches assigning an "instance number". 

However, Hrischuk mentions only once the step or element of assigning an "instance 
number" as follows: 

A process thread is identified with the process scenario name and the 
process thread identifier, such as <L,k>. If an object-oriented system is 
being monitored then the object identifier should include class name and 
jnstance number of an executing object. 
(Hrischuk Col. 23, lines 19 • 22, emphasis added) 

A text search of the HTML version of the Hrischuk patent on the USPTO database for 
the term "instance number" finds only this single occurrence in the entire Hrischuk disclosure of 
the term "instance number". No further citations were provided in the rationale for the 
rejections to support the conclusion that Hrischuk teaches the instance number assignment 

process we have claimed. 

As can be seen from this passage, Hrischuk is silent as to how their instance number is 
assigned. For example, is it pre-assigned, or is it a unique value? Is it generated using a pseudo- 
random generator? Is it generated during runtime, during compilation, or by the software 
designer himself? Does Hrischuk's invention make sure that no two module identifiers are the 
same value? 
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We have claimed that our invention prevents instance identifiers from having the same 
value (Claims 1 and 7), and in particular that the identifier values are generated using a counting 
process (Claims 2 and 8). Claims 3 and 9 also include the steps or limitations as claimed in 
Claims 1 and 7, as they depend from these claims, respectively. Hrischuk is silent as to these 
teachings, and therefore the rejections of claims 1 - 3 and 7 - 9 should be reversed. 

Further, Hrischuk is also silent as to where their instance numbers are stored. For 
example, are they stored on a stack, as we have claimed, or in a data structure, such as a 
variables or an array of variables? We have claimed "pushing" the instance identifier, with 
certain other data, onto a processing stack. Hrischuk is silent as to these teachings, and 
therefore the rejections of claims 1 - 3 and 7 - 9 should be reversed. 

Still further, Hrischuk uses a communications protocol, not stack signatures, to record 
events and data associated with events: 

In order to record sufficient Information regarding software 
process execution, angio tracing is employed. Angio tracing according to 
the invention identifies soenario and potential precedence relationships 
between recorded events of an application and properly characterises 
concurrency. Angio tracing according to the invention characterises 
communication protocol elements i n the form of blocking request 
initiation, non-blocking request initiation, request acceptance, 
synchronisation acceptance, sending a reply to a blocking request 
initiation, and acceptance of a reply. Angio tracing supports integration of 
information from a heterogeneous environment because it is independent 
of implementation technology, execution environment, and monitoring 
approach. Optionally, multiple angio traces are recorded simultaneously. 
Automated trace analysis is possible because angio tracing according to 
an embodiment is based on a formal model. (Col. 16, lines 38 - 32, 
emphasis added) 

RPC, synchronisation, and asynchronous communication 
protocols are also characterised by the following elements: 

Blocking request initiation: An object cannot proceed until it 
receives a reply to a request it has just made; 
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Non-blocking request initiation: An initiating or forwarding object 
makes a service request to another object and the initiating object does 
not block to wait for a reply; 

Request acceptance: A blocked responding object accepts a new 
service request and begins a new period; 

Synchronisation acceptance: A responding object is already 
processing a service request but it is blocked, waiting to accept another 
message to continue the service; 

Sending a reply to a blocking request: A replier object sends the 
reply to the blocked initiating object; and, 

Acceptance of a reply: A blocked initiating object receives the 
reply and continues execution. (Col. 21, lines 6 - 23) 

A text search the HTML version of the Hrischuk patent on the USPTO database for the 
terms "stack" and "heap", where "heap" is a term used sometimes in place of "stack", finds no 
occurrences of the terms "stack" or "heap" in the entire disclosure. 

For these reasons, Kaneshiro in view of Hrischuk fails to teach generating an instance 
value according to our process of assigning instance values, and storing instance values in 
signature blocks in a computer stack. Reversal of the rejections of Claims 1 - 3 and 7 - 9 is 
requested. 

Rejections of Claims 4 - 6 and 10 - 12 under 35 U.S.C. S1 03(al over Kaneshiro in 
view of Hrischuk in further view of Ramkumar 

Claims 4 - 6 depend from Claim 1, and Claims 10-12 depend from Claim 7. According 
to the rationale for the rejections of these claims, Ramkumar is not employed to teach the 
missing steps or limitations as discussed in the foregoing paragraphs regarding the rejections of 
claims 1 and 7. For these same reasons, reversal of the rejections of claims 4 - 6 and 10 - 12 is 
requested. 

Rejections of Claims 13 - 15 under 35 U.S.C. §103fa) over Kaneshiro in view of 
Hrischuk in further view of Ramkumar 

Claim 13 is an independent system claim, and Claims 14 and 15 depend from Claim 13. 
In particular, we have claimed in Claim 13 a compiler means for inserting stack signing 
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software, wherein the stack signing software assigns identifier values in a manner that prevents 
identifiers of instances from having the same value, as previously discussed with regard to the 
rejections of Claims 1 and 7. Claims 14 and 15 include these same elements or limitations. 
According to the rationale for the rejections of these claims, Ramkumar is not employed to teach 
the missing steps or limitations as discussed in the foregoing paragraphs regarding the rejections 
of claims 1 and 7. For these same reasons, reversal of the rejections of claims 13-15. 

Rejections of Claims 16 - 17 under 35 U.S.C. §103fa) over Kaneshiro in view of 
Hrischuk in farther view of Voas 

In the rationale for the rejections of Claims 16-17, Voas was employed to teach our 
claimed step, element or limitation of encryption of the stack signature, 

Voas discloses encryption of "test data" in order to transfer collected data from an 
application program being used "in the field" (e.g. on a client computer) to a certification 
laboratory (their "SCL"). This is done to protect the data in transit as it is being transmitted from 
one computer to another, and not to protect data stored on a computer stack. 

Voas is silent as to encrypting signatures which are stored on a computer or processing 
stack as we have claimed. A "computer stack" is not part of a transmission protocol between 
two computers, but instead is an internal operational component of the computer's processor 
and/or operating system. While the term "protocol stack" often is used to refer to a 
communication protocol which is divided into "layers" of functionality, the term "processing 
stack" is not synonymous with the term "protocol stack*'. Further, the term "push" is not used 
with a protocol stack, but is commonly used when referring to moving data into or onto a 
processing stack. 

For example, Random House Webster's Computer and Internet Dictionary, Third 
Edition, (copyright 1999), defines a stack as follows: 

stack 

1. In programming, a special type of data structure in which items are removed in 
the reverse order from that in which they are added, so the most recently added 
item is the first one removed. This is also called last-in, first-out (LIFO). Adding 
an item to a stack is called pushing. Removing an item from a stack is called 
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popping. 

2. In networking, short for protocol stack. 

3. In Apple Computer's HyperCard software system, a stack is a collection of 
cards. 

For these reasons, neither Kaneshiro, Hrischuk, or Voas teach encryption of stack 
signatures as we have claimed, wherein the identifier information is encrypted and stored on a 
processing stack. Reversal of the rejections of Claims 1 6 - 1 7 is requested. 

maim Ifi under 35 U.S.C. S103(al over Kanes hiro in view of Hrischok in farther 
view of Carter 

Claim 18 claims generation of unique instance identifiers to be stored on a processing 
stack as previously discussed relative to Claim 1, as Claim 18 depends from Claim 1. Thus, the 
rejections of Claim 18 fail to teach the steps and limitations as set forth in the foregoing 
arguments requesting reversal of the rejection of Claim 1. 

Claim 18 also sets forth a limitation regarding the method of generation of the instance 
identifier using a pseudo-random number generator, instead of or in cooperation with a counter. 
This embodiment helps assure instance number uniqueness without complicated inter-process 
communications to check out instance numbers. In the rationale for the rejection of Claim 18, it 
was reasoned that Carter teaches this step or limitation. 

Carter is directed towards "building" or "compiling" new versions of programs which are 
backwards compatible with older versions of the same program, and especially towards building 
a new version "object servers" which can be utilized by older programs which interfaced to and 
used the previous version of the object server. 

The examiner has cited the following as teaching our claimed process of generation of 
instance numbers using pseudo-random number generation: 

When automatic version compatible object server building is not 
selected (such as when compiling an initial version of an object server), 
compiler 52 generates a new vtable offsets and Identifiers in steps 
140-150. The resulting object server 92 therefore is extremely unlikely to 
support the same interfaces as any other object server. (The bit-length of 
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the library ID, CLSIDs, and IIDs, and OLE 2's rand om generation 
routine used In the preferred embodiment to ge nerate these 
identifiers, guarantees to a very high pro bability that no two 
Identifiers generated bv compiler 62 are identical. ) When automatic 
version compatible object server building is selected, however, compiler 
52 first performs process 76 (FIG. 6) to determine whether new object 
server 64 (FIG. 2) can be made version compatible with existing object 
server 66 (FIG. 2). Then, in process 78 (FIG. 5), compiler assigns vtable 
offsets and identifiers of new object server according to the new object 
server's compatibility as described more fully below. (Col. 12, lines 44 - 
61, emphasis added) 

Clearly, Carter is generating their identifiers during compilation, not during runtime or 
during execution of the code to be monitored. Additionally, the generation of Carter's 
identifiers is being performed by a compiler, not by the code inserted into the actual application 
program. 

In Claim 1 8 (and Claim 1), we have specified that our instance numbers are generated 
"upon execution of said executable re-entrant or object-oriented code modules". Carter is silent 
as to such runtime generation of instance numbers. Further, as it would be impossible at the time 
of source code compilation to know how many instances of a particular object would be 
simultaneously instantiated during later runtime, it would be impossible to generate our instance 
numbers during compilation or build of a program. 

For these reasons, Kaneshiro in view of Hrischuk in further view of Carter does not teach 
all of our claimed elements, steps, or limitations as set forth in Claim 18. Reversal of the 
rejection of Claim 1 8 is requested. 



Respectfully Submitted, 
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Clean Form of Amended Claims 

Claim 1 (previously amended): 

A method for marking a processing stack with signatures to indicate which portions of 
the stack were utilized by one or more re-entrant or object-oriented programming 
software code modules, said method comprising the steps of: 

inserting stack signing software into one or more re-entrant or object-oriented 
programming code modules stored in a computer-readable medium; 

producing one or more executable programs containing one or more executable 
re-entrant or object oriented programming code modules containing said inserted stack 
signing software; 

upon execution of said executable re-entrant or object-oriented code modules, 
assigning unique module identifier values to said code modules by said stack signing 
software, said stack signing software preventing module identifiers from having a same 
value for multiple instances of any re-entered or multiply instantiated code module, and 
pushing onto said processing stack said stack signatures within stack frames allocated to 
said code modules. 

Claim 2 (previously amended): 

The method as set forth in Claim 1 further comprising the steps of: 

generating an instance count for each instantiation of executable code module in 
said stack signature for each object instance dynamically created during runtime of a re- 
entrant executable code module; and 

pushing onto said processing stack said instance count. 

Claim 3 (original): 

The method as set forth in Claim 1 further comprising the step of pushing onto said stac 
an entry/exit indicator associated with said unique module identifier. 
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Claim 4 (original): 

The method as set forth in Claim 1 further comprising the step of inserting 
stack signature marking software segments into application source code, said 
insertion step being performed prior to compilation of said application source 
code. 

Claim 5 (original): 

The method as set forth in Claim 4 further comprising the step of providing a 
global control which indicates all application source code modules are to have 
stack signature marking software segments inserted into them during a given 
compilation job. 

Claim 6 (original): 

The method as set forth in Claim 4 further comprising the step of providing a selective 
control which indicates only certain application source code modules are to have stack 
signature marking software segments inserted into them during a given compilation job 
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Claim 7 (previously amended): 

A computer readable medium encoded with software for marking a processing 
stack with signatures to indicate which portions of the stack were utilized by 
which application code modules, said software causing a processor to perform 
the steps of: 

inserting stack signing software into one or more re-entrant or object-oriented 
programming code modules stored in a computer-readable medium; 

producing one or more executable programs containing one or more executable 
re-entrant or object oriented programming code modules containing said inserted stack 
signing software; 

upon execution of said executable re-entrant or object-oriented code modules, 
assigning unique module identifier values to said code modules by said stack signing 
software, said stack signing software preventing module identifiers from having a same 
value for multiple instances of any re-entered or multiply instantiated code module, and 
pushing onto said processing stack said stack signatures within stack frames allocated to 
said code modules. 

Claim 8 (original): 

The computer readable medium as set forth in Claim 7 further comprising software to 

perform the steps of: 

generating an instance number for each instantiation of a code module; and 
pushing onto said processing stack said instance numbers associated with said 

unique module identifier values. 

Claim 9 (original): 

The computer readable medium as set forth in Claim 7 further comprising software for 
performing the step of pushing onto said stack an entry/exit indicator associated with sai( 
unique module identifier. 
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Claim 10 (original): 

The computer readable medium as set forth in Claim 7 further comprising software for 
performing the step of inserting stack signature marking software segments into 
application source code, said insertion step being performed prior to compilation of said 
application source code. 



Claim 1 1 (original): 

The computer readable medium as set forth in Claim 10 further comprising 
software for performing the step of providing a global control which indicates 
all application source code modules are to have stack signature marking 
software segments inserted into them during a given compilation job. 

Claim 12 (original): 

The computer readable medium as set forth in Claim 10 further comprising 
software for performing the step of providing a selective control which 
indicates only certain application source code modules are to have stack 
signature marking software segments inserted into them during a given 
compilation job. 
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Claim 13 (previously amended): 

A system for inserting stack signature marking code segments into application 
software modules prior to compilation, said system cooperating with a compiler and 
comprising: 

a control means operable by a user to indicate whether or not to insert stack 
signature marking code segments into application software modules; 

a code insertion means which, responsive to the operation of the control means, 
searches for entry points and exits points in application software modules and inserts 
stack signature marking code segments following each entry point and prior to each exit 
point into said application software modules; 

a compiler means for producing one or more executable programs containing one 
or more executable re-entrant or object oriented programming code modules containing 
said inserted stack signing software; and 

a debugger means configured to, upon execution of said executable re-entrant or 
object-oriented code modules, assign unique module identifier values to said code 
modules by said stack signing software, said stack signing software preventing module 
identifiers from having a same value for multiple instances of any re-entered or multiply 
instantiated code module, and to push onto said processing stack said stack signatures. 

Claim 14 (previously amended): 

The system of Claim 13 wherein said control means comprises a global control means for 
indicating insertion of stack signature marking code segments are to be inserted into all 
application software modules to be compiled. 

Claim 15 (previously amended): 

The system of Claim 13 wherein said control means comprises a selective 
control means for indicating specific applications software modules or groups 
of application software modules into which stack signature marking code 
segments aTe to be inserted. 
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Claim 16 (previously added): 

The method as set forth in Claim 1 further comprising encrypting at least a portion of 

said stack signature. 

Claim 17 (previously added): 

The method as set forth in Claim 2 further comprising encrypting said instance number i 

said stack signature. 



Claim 18 (previously added): 

The method as set forth in Claim 1 wherein said step of pushing stack signatures onto 

said processing stack comprises: 

generating a pseudo-random identifier for each object instance dynamically 
created during runtime of a re-entrant executable code module; and 

including said pseudo-random identifier in said stack signature pushed onto said 
processing stack. 
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Evidence Appendix 
per 37 CFR §4U7(c)(l)(ix) 

No evidence has been submitted by applicant or examiner pursuant to 37 CFR §§1 .130, 
1.131, or 1.132. 
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Related Proceedings Appendix 
per 37 CFR §41.37(c)(l)(x) 

No decisions have been rendered by a court or the Board in the related proceedings as 
identified under 37 CFR §41.37(c)(l)(ii). 
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